Thanks!

Should we put this behind a jupyterlite-sphinx flag?

I don't think we should this can always be overridden with custom css, the same way we can change the buttons colors or position on the page.

Ok, sounds good!

@martinRenou After this gets in, can we do a new release?

Update: Actually, I think there's one more thing I'd like to see go in first. An option to put a warning cell at the top of the generated notebooks in the TryExamplesDirective like Scikit-Learn does to warn users that the interactive examples feature is experimental, to expect slow load times, and give a link to where to submit issues. I'll make an issue for that today, and submit a PR later.

Sure thing! You should have the rights to make releases. Feel free to make it if you want!

To do this you need to go at the Actions tab of the repo, then manually trigger the Step 1: Prep Release. This should publish a draft release in https://github.com/jupyterlite/jupyterlite-sphinx/releases once done. Then you can manually run the Step 2: Publish Release to finalize it.

Sure thing! You should have the rights to make releases. Feel free to make it if you want!

To do this you need to go at the Actions tab of the repo, then manually trigger the Step 1: Prep Release. This should publish a draft release in https://github.com/jupyterlite/jupyterlite-sphinx/releases once done. Then you can manually run the Step 2: Publish Release to finalize it.

Thanks @martinRenou! That's very convenient. I'll make one after things get settled.

It seems that the button is not hidden on my phone when I hold it horizontally

but is hidden when held vertically

@Carreau, could we use javascript to conditionally hide the button based on the area of the screen? Or would it be better just to use plain css and hide based on max-width and max-height? Also, should we take tablets into account?

Also, should we take tablets into account?

Often tablets will be used in school/university settings where it would be helpful to be able to try the code. It is a shame there is no "low data connection" indicator, this seems like it should be a solved problem.

Is it possible to, instead of tinkering with screen sizes, retrieve at the device settings and warn users with a pop-up / differently-coloured or greyed-out button that using the kernel will be slower on mobile devices?

Also, should we take tablets into account?

Often tablets will be used in school/university settings where it would be helpful to be able to try the code. It is a shame there is no "low data connection" indicator, this seems like it should be a solved problem.

@Carreau mentioned navigator.connection here which should work in principle, but isn't available on ios safari.. It seems like they don't want to implement it because of privacy concerns. This issue, https://bugs.webkit.org/show_bug.cgi?id=185697, has been open for almost 6 years now.

Is it possible to, instead of tinkering with screen sizes, retrieve at the device settings and warn users with a pop-up / differently-coloured or greyed-out button that using the kernel will be slower on mobile devices?

Not sure. I think the issue of having a pop-up or changing the color of the button is orthogonal to detecting if we're dealing with a device using mobile data. @Carreau mentioned adding a warning dialogue with javascript, so I think that is the plan eventually. I don't know much about web dev, so I'm not sure what you mean by retrieving at the device settings. Based on the research I've done this morning, I think the only things we have to go on are the user agent, screen width, screen height, and on some platforms navigator.connection. We could probably come up with a good heuristic that takes all of these things into account, but for now its probably best to start simple.

we can likely implement a dialog we a "don't ask me again", and tweak the logic of when to show it later.

@martinRenou, it seems like I might not have the right permissions to make a release. I tried running the Step 1: Prep Release action like you described above, and the action failed. The logs say

  File "/home/runner/work/_actions/jupyter-server/jupyter_releaser/v2/jupyter_releaser/actions/common.py", line 19, in setup
    return prepare_environment(fetch_draft_release=fetch_draft_release)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/runner/work/_actions/jupyter-server/jupyter_releaser/v2/jupyter_releaser/util.py", line 618, in prepare_environment
    raise RuntimeError(msg) from None
RuntimeError: Could not get user permission level, assuming user was not admin!

@steppi can you try again?

@steppi can you try again?

It worked this time. Thanks!

@martinRenou, I just selected the default options, which prepared release 0.11.1, but I think this makes more sense as an 0.12.0, since there were a number of enhancements, and having the TryExamples directive no longer work on small screens could be seen as backwards incompatible.

Right, you can remove the release draft in https://github.com/jupyterlite/jupyterlite-sphinx/releases. Then I believe you can rerun with the version specifier "minor".

Yay!! Thanks for the release!!